I. Field
The present invention generally relates to packet data communications, and more particularly, to handoff supports for networks with different link establishment protocols which executions are often required prior to any packet data communications among networks.
II. Background
Interconnecting of networks globally allows information to be swiftly accessed irrespective of geographical distances. FIG. 1 shows a simplified schematic drawing of the global connection of networks, commonly referred to as the Internet signified by the reference numeral 20. The Internet 20 is in essence many networks with different levels of hierarchy linked together. The Internet 20 is operated under the IP (Internet Protocol) promulgated by the IETF (Internet Engineering Task Force). Details of the IP can be found in RFC (Request For Comments) 791 published by the IETF.
Connected to the Internet 20 are various individual networks, sometimes called LANs (Local Area Networks) or WANs (Wide Area Networks) depending on the network sizes. Shown in FIG. 1 are some of such networks 22, 24, 26 and 28.
Within each of the networks 22, 24, 26 and 28, there can be various pieces of equipment connected to and in communication with each other. Examples are computers, printers, and servers, to name just a few, which are commonly called nodes. When a node communicates beyond its own network via the Internet 20, an IP address needs to be assigned to the node. The assignment of the IP address can be manual or automatic. The manual assignment of the IP address can be performed by a network administrator, for example. More often, the IP address is automatically assigned, for instance, by a dedicated server in the LAN or WAN.
Take an example for illustration. Suppose a node 30 in the network 22 attempts to send a data packet to another node 37 in the network 24. Under the IP, each data packet needs to have a source address and a destination address. In this case, the source address is the address of the node 30 in the network 22. The destination address is the address of the node 37 in the network 24.
Oftentimes, node-to-node communications are required prior to network access, such as accessing other networks via the Internet 20. Take yet another example for illustration. Suppose the node 30 in the network 22 is a laptop computer. The laptop computer node 30 does not have direct access to the network 22. Nevertheless, the laptop computer node 30 may reach a NAS (Network Access Server) 32 in the network 22 via some other means, such as by dialing up a wired modem through a telephone line, for example. In that case, the node 30 typically establishes a PPP (Point-to-Point Protocol) session with the NAS (Network Access Server) 32 in the network 22. Packet data communications thereafter established between the node 30 and the network 22, or any other networks via the Internet 20, will be exchanged through the wired modem and the telephone line. If the modem transmits and receives signals serially and asynchronously through the telephone line, data packets exchanged over the telephone line also have to be framed accordingly to suit the serial and asynchronous modem link.
Advances in wireless technologies allow nodes to move away from their originally registered network to another network. For instance, referring back to FIG. 1, the node 30, instead of permanently wired to the network 22, can be a wireless device, such as a PDA (Personal Device Assistant), a cellular phone, or a mobile computer. The wireless node 30 can travel beyond the boundary of its home network 22. Thus, the node 30 may roam away from its home network 22 to a foreign network 28. To gain access of the network 28, or to be connected to other networks via the Internet 20, the node 30 also typically establishes a PPP session with a NAS 33 in the network 28. Communications between the node 30 and the NAS 33 in this case are through the air link. Again, data packets exchanged over the air link also have to be framed to fit into the format which is negotiated during the PPP session between the node 30 and the NAS 33.
The bulk of the PPP is described in RFCs 1661 and 1662 published by the IETF. The PPP is in essence an exploratory and negotiating session between nodes, during which session, the nodes find out from each other's resources in terms of capability and availability and finally converge to a set of mutually acceptable parameter options, prior to any network traffic flow. Because a PPP session often needs to be established prior to network access, the PPP is sometimes called a “network interface layer protocol.” However, other similar terms are also commonly used, including “link establishment protocol” and “Layer-2 protocol.” Hereinbelow, the terms “network interface layer protocol,” “link establishment protocol” and “Layer-2 protocol” are used interchangeably.
FIG. 2 shows a sequence flow diagram of an exemplary PPP communication session 34 in which the node 30 in the network 28 seeks to establish a communication link with the NAS 33 for gaining access to the Internet 20.
The PPP has a number of protocol components. In the exemplary PPP session shown in FIG. 2, the PPP has the LCP (Link Control Protocol) 36, CHAP (Challenge/Handshake Authentication Protocol) 38, and IPCP (Internet Protocol Configuration Protocol) 40 as components.
First, upon completion of the physical link, that is, the node 30 and the NAS 33 are capable of reaching each other at the hardware level, for example, there is a need to go through the LCP 36. The LCP 36 serves the purpose of establishing the basic communication link between the node 30 and the NAS 33. During the LCP 36, the node 30 and the NAS 33 exchange and negotiate essential communication parameter options with each other. The options can include, maximum size of the data packet through the link, parameters relating to quality control, HDLC (High Level Data Link Control) header field compression scheme used, and whether the peer is willing to be authenticated.
The processes for the LCP 36 are more or less operated under a handshake etiquette. First, the requesting party proposes one or more parameters by sending a Configure Request message. If any parameter is not recognized by the receiving party, the receiving party responds back with a Configure Reject message. If the rejected parameter is fatal to the sought link, the requesting party then has to terminate the PPP session.
On the other hand, if the parameter is recognized but the option related to the parameter is not acceptable, the responding party sends back a Configure Nak message. The requesting party again can either terminate the PPP session or send another Configure Request message with a different option for the same parameter.
All parameters with the associated options have to be negotiated and settled in manner as described above. Several rounds of negotiation may be required, as shown in FIG. 2. If the requesting party determines that all the parameters needed are acceptable to the responding party, the requesting party sends a final Configure Ack message to the responding party. Once both parties have sent Configure Ack messages, they then transition to the authentication phase.
To ensure the parties are authorized, authentication has to be carried out. One way to perform authentication is to use the other PPP component CHAP 38. It is typically the NAS 33 that initiates the CHAP 38 to verify the identity of the node 30. During the CHAP 38, the NAS 33 sends a message called a challenge message to the node 30. Under the CHAP, there is a shared secret which is used along with the challenge message that is used to calculate a response message using a pre-agreed upon algorithm. The node 30 then sends the response message generated by the secret algorithm to the NAS 33. The NAS 33 thereafter compares the received response message with the message calculated by the NAS 33 itself. If there is a comparison match, the node 30 is said to pass the CHAP 38 in which the NAS 33 sends a CHAP Success message to the node 30. Otherwise, a CHAP Failure message is sent by the NAS 33.
Alternatively, instead of the CHAP 38, authentication can be accomplished by going through a PAP (Password Authentication Protocol). In the PAP, the node 30 merely sends the NAS 33 a username and password for verification. If verified, the node 30 is said to pass the PAP.
If the node 30 needs IP access, information relating to IP again needs to be exchanged and negotiated. For example, among other things, the node 30 may need to have an assignment of an IP address in order to access the Internet 20 (FIG. 1) in accordance with the IP. To accomplish this end, negotiation and exchange of parameter options under the IPCP 40 commence. In the exemplary PPP session 34, the node 30 initially requests an IP address 0.0.0.0 from the NAS 33. In response, the NAS 33 sends a Configure Nak message, suggesting the node 30 uses the IP address a.b.c.d. If accepted, the node 30 confirms the use of the IP address a.b.c.d by sending the NAS 33 another message for acknowledgement.
Finally, when the node 30 agrees to all the parameters negotiated during the IPCP 40, the node 30 sends an acknowledge message to the NAS 33. User data of the network access session are thereafter exchanged. The IP data packets of the network traffic are encapsulated into the PPP frames with parameters negotiated during the LCP 36 earlier.
At the end of the network access, either the node 30 or the NAS 33 may send a Terminate Request message to the other, which thereafter responds back with a Terminate Ack message and conclude the communication session.
As can be seen in FIG. 2 and described above, there are quite a number of messages exchanged between the node 30 and the NAS 33 during the PPP session 34. As such, considerable time duration is involved. This is especially true if the PPP session 34 is negotiated over a slow link with high data latency.
To expedite the initial link establish process between the node 30 and the NAS 33, various protocols other than the PPP have been proposed. An example of such protocols is taught in U.S. patent application Ser. No. 11/193,068, entitled “Fast Link Establishment for Network Access,” filed on Jul. 28, 2005 (hereinafter, the “'068” patent application). The '068 patent application which is assigned to the assignee hereof is hereby expressly incorporated by reference herein in its entirety. Hereinbelow, any link establishment protocol other than the PPP is called a non-PPP.
However, problems arise in a communication system in which some networks support non-PPPs while others do not. The problems can further be compounded when mobile nodes roam around the different networks with different link establishment protocols.
Take another example for illustration. Reference is now directed back to FIG. 1. Suppose the node 30, after migrating to the network 28, establishes a communication link with the NAS 33 via a non-PPP session. User data is thereafter exchanged between the node 30 and the NAS 33. Further suppose that in the midst of exchanging user data, the node 30 moves to yet another network, such as the network 26. If the network 26 is similar to the network 28 is every aspect regarding physical and protocol implementations, including the network interface layer protocol implementation, a streamline handoff scheme can be devised. After reaching the territory of the network 26, the network 28 can hand over the data processing duties to the network 26 which can then take over the packet data communications functions previously held by the network 28.
However, the networks 28 and 26 are often not similar in hardware and link layer implementation. For example, suppose the network 28 supports not only the PPP but also another non-PPP as the network interface layer protocols. On the other hand, the network 26 supports only the PPP as the network interface layer protocol but no others. After migrating to the network 26 from the network 28 and to continue with network access, the node 30 needs first to establish another network interface layer protocol session with the NAS 35 in the network 26, such that packet data communications established thereafter conform to the physical link established between the node 30 and the NAS 35 in the network 26. If the node 30 is not adapted to smoothly invoke the conventional PPP required by the network 26, the node 30 can be totally cut out of network access.
Accordingly, there is a need to provide reliable handoff processes for migrating nodes seeking network accesses among different networks supporting different network interface layer protocols.